Field of the Invention
With the continuous improvement in computing and communication technologies viewing media streams on demand is becoming increasingly popular. A client-server paradigm with a streaming server transmitting the media stream selected by an end-user associated with a client device, to be also referred to as client, is often used for supporting such applications. Various types of client devices may be deployed by users. These include desktop computers, television sets as well as mobile wireless devices such as cell phones and personal digital assistants. Typically, such a client device is associated with a media player that provides the end-user with the interface required for interacting with the streaming server. Both stored media streams, such as movies, available at the streaming server, or live media streams, including sporting events and live concerts distributed in real time by the streaming server, are viewed by end-users.
A Real Time Streaming Protocol (RTSP), also referred to as standard RTSP, is typically used in supporting the client-server communication in case of both types of systems that handle stored as well as live media streams, see, for example a Request for Comments (RFC) 2326 of the Internet Engineering Task Force (IETF) “Real Time Streaming Protocol” (RTSP) by Schulzrinne et al. dated April 1998. RTSP allows a client to control the transmission of channels, each of which corresponds to a media stream provided by the streaming server. The client uses Video Cassette Recorder (VCR)-like commands, such as play and seek, for accessing media streams on streaming servers. The actual transmission and reception of the media streams, however, are not part of RTSP that focuses on controlling the viewing of the media streams by the client. Most RTSP servers deploy the Real Time Transport Protocol (RTP) as the transport protocol for the actual transmission of audio/video data. A number of RTSP messages are described below, see, for example an article in Wikipedia entitled “Real Time Streaming Protocol” published on-line at the URL “http://en.wikipedia.org.wiki/Real_Time_Streaming_Protocol” before the priority date of the present invention.
DESCRIBE: This message is sent typically for launching a RTSP session. The message includes a RTSP URL required for identifying the media stream to be played and the type of reply data that can be handled. The reply to this message includes the description of the multimedia session prepared by using the Session Description Protocol (SDP). SDP is a protocol used for describing multimedia sessions for session announcement, session invitation, and other forms of multimedia session initiation. The session description includes a list of the media streams controlled with the help of the URL specified in the DESCRIBE message. Typically, there is one media stream for audio and a separate media stream for video.
SETUP: This message specifies how a single media stream must be transported. This is used before a play request is sent by the client to the streaming server. The request contains the media stream URL and a transport specifier that includes a local port for receiving RTP data corresponding to the audio or the video stream.
PLAY: This message is sent by the client to play a media stream. Multiple PLAY requests can be sent in succession. The URL associated with this request may be an aggregate URL when the client wishes to play all media streams, or a single media stream URL when the client wishes to play only a single stream. A range parameter included with the PLAY request is used to determine the point in the media stream from which transmission is to begin. If no range is specified, the stream is played from the beginning to the end.
TEARDOWN: This message is used to terminate an existing RTSP session. It stops all media streams and clears all data related to the RTSP session on the streaming server.
Viewers of live media streams may desire to switch from a channel currently being viewed to a new channel. Systems that use the standard RTSP protocol may need to terminate an existing RTSP session and start a new RTSP session for playing the new channel desired by the client. This disruptive and delay causing process can lead to a dissatisfied user. Although extensions to the RTSP protocol are being proposed for performing fast channel switching (FCS) within the existing RTSP session, most existing media players are not equipped to deal with this new extension to the RTSP protocol. Moreover, handling the extension to the RTSP protocol often requires additional resources, which may not be available for resource constrained mobile devices.
Thus, there is an existing need in the industry for an improved and effective method and system for fast channel switching of live media streams using existing control messages, which would avoid or mitigate the deficiencies of the prior art.